This works better with non-LLVM codegen backends.

…update_cg_gcc_2025-11-26

…26, r=GuillaumeGomez

cg_gcc subtree sync

cc `@antoyo`

There are major questions remaining about the reentrancy that this
allows. It doesn't have any users on github outside of a single project
that uses it in a panic=abort project to show backtraces. It
can still be emulated through #[alloc_error_handler] or
set_alloc_error_hook depending on if you use the standard library or
not. And finally it makes it harder to do various improvements to the
allocator shim.

This register is only supported on the *powerpc*spe targets. It is
only recognized by LLVM. gcc does not accept this as a clobber, nor
does it support these targets.

This is a volatile register, thus it is included with clobber_abi.

…update_cg_gcc_2025-12-04

…04, r=GuillaumeGomez

cg_gcc subtree update

cc `@antoyo`

r? ghost

Since GCC is not multi-target, we need multiple libgccjit.so.
Our solution to have a directory per target so that we can have multiple
libgccjit.so.

Remove -Zoom=panic

There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through `#[alloc_error_handler]` or `set_alloc_error_hook` depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim.

With this PR the sole remaining symbol in the allocator shim that is not effectively emulating weak symbols is the symbol that prevents skipping the allocator shim on stable even when it would otherwise be empty because libstd + `#[global_allocator]` is used.

Closes rust-lang/rust#43596
Fixes rust-lang/rust#126683

Run clippy on cg_gcc in CI

This is to prevent [this issue](rust-lang/rust#149449 (comment)): in cg_gcc repository, we run clippy on our code but not in here, which can create issues.

cc ````@antoyo````
r? ````@Kobzol````

…let ... else return`

Update `rustc_codegen_gcc` rotate operation document

## Description

This PR resolves a TODO comment in the `rustc_codegen_gcc` backend by documenting that the rotate operations (`rotate_left` and `rotate_right`) already implement the optimized branchless algorithm from comment.

The existing implementation already uses the optimal branchless rotation pattern:
- For left rotation: `(x << n) | (x >> (-n & (width-1)))`
- For right rotation: `(x >> n) | (x << (-n & (width-1)))`

This pattern avoids branches and generates efficient machine code across different platforms, which was the goal mentioned in the original TODO.

## Changes

- Removed the TODO comment that suggested implementing the algorithm from https://blog.regehr.org/archives/1063

Use `let...else` instead of `match foo { ... _ => return };` and `if let ... else return`

Overhaul filename handling for cross-compiler consistency

This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).

This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).

In order to achieved consistency multiple steps are being taken by this PR:
 - by making `RealFileName` immutable
 - by only having `SourceMap::to_real_filename` create `RealFileName`
   - currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
 - by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
   - this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename

In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.

This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.

Unblocks rust-lang/rust#147611
Fixes rust-lang/rust#148328

Introduces `BackendRepr::ScalableVector` corresponding to scalable
vector types annotated with `repr(scalable)` which lowers to a scalable
vector type in LLVM.

Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>